home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1542.txt < prev    next >
Text File  |  1994-08-01  |  53KB  |  1,292 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           W. Wimer
  8. Request for Comments: 1542                    Carnegie Mellon University
  9. Updates: 951                                                October 1993
  10. Obsoletes: 1532
  11. Category: Standards Track
  12.  
  13.  
  14.         Clarifications and Extensions for the Bootstrap Protocol
  15.  
  16. Status of this Memo
  17.  
  18.    This RFC specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" for the standardization state and status
  22.    of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    Some aspects of the BOOTP protocol were rather loosely defined in its
  27.    original specification.  In particular, only a general description
  28.    was provided for the behavior of "BOOTP relay agents" (originally
  29.    called BOOTP forwarding agents").  The client behavior description
  30.    also suffered in certain ways.  This memo attempts to clarify and
  31.    strengthen the specification in these areas.  Due to some errors
  32.    introduced into RFC 1532 in the editorial process, this memo is
  33.    reissued as RFC 1542.
  34.  
  35.    In addition, new issues have arisen since the original specification
  36.    was written.  This memo also attempts to address some of these.
  37.  
  38. Table of Contents
  39.  
  40.    1. Introduction.................................................  2
  41.    1.1 Requirements................................................  3
  42.    1.2 Terminology.................................................  3
  43.    1.3 Data Transmission Order.....................................  4
  44.    2. General Issues...............................................  5
  45.    2.1 General BOOTP Processing....................................  5
  46.    2.2 Definition of the 'flags' Field.............................  5
  47.    2.3 Bit Ordering of Hardware Addresses..........................  7
  48.    2.4 BOOTP Over IEEE 802.5 Token Ring Networks...................  8
  49.    3. BOOTP Client Behavior........................................  9
  50.    3.1 Client use of the 'flags' field.............................  9
  51.    3.1.1 The BROADCAST flag........................................  9
  52.    3.1.2 The remainder of the 'flags' field........................  9
  53.    3.2 Definition of the 'secs' field.............................. 10
  54.    3.3 Use of the 'ciaddr' and 'yiaddr' fields..................... 10
  55.  
  56.  
  57.  
  58. Wimer                                                           [Page 1]
  59.  
  60. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  61.  
  62.  
  63.    3.4 Interpretation of the 'giaddr' field........................ 11
  64.    3.5 Vendor information "magic cookie"........................... 12
  65.    4. BOOTP Relay Agents........................................... 13
  66.    4.1 General BOOTP Processing for Relay Agents................... 14
  67.    4.1.1 BOOTREQUEST Messages...................................... 14
  68.    4.1.2 BOOTREPLY Messages........................................ 17
  69.    5. BOOTP Server Behavior........................................ 18
  70.    5.1 Reception of BOOTREQUEST Messages........................... 18
  71.    5.2 Use of the 'secs' field..................................... 19
  72.    5.3 Use of the 'ciaddr' field................................... 19
  73.    5.4 Strategy for Delivery of BOOTREPLY Messages................. 20
  74.    Acknowledgements................................................ 21
  75.    References...................................................... 22
  76.    Security Considerations......................................... 23
  77.    Author's Address................................................ 23
  78.  
  79. 1. Introduction
  80.  
  81.    The Bootstrap Protocol (BOOTP) is a UDP/IP-based protocol which
  82.    allows a booting host to configure itself dynamically and without
  83.    user supervision.  BOOTP provides a means to notify a host of its
  84.    assigned IP address, the IP address of a boot server host, and the
  85.    name of a file to be loaded into memory and executed [1].  Other
  86.    configuration information such as the local subnet mask, the local
  87.    time offset, the addresses of default routers, and the addresses of
  88.    various Internet servers can also be communicated to a host using
  89.    BOOTP [2].
  90.  
  91.    Unfortunately, the original BOOTP specification [1] left some issues
  92.    of the protocol open to question.  The exact behavior of BOOTP relay
  93.    agents formerly called "BOOTP forwarding agents") was not clearly
  94.    specified.  Some parts of the overall protocol specification actually
  95.    conflict, while other parts have been subject to misinterpretation,
  96.    indicating that clarification is needed.  This memo addresses these
  97.    problems.
  98.  
  99.    Since the introduction of BOOTP, the IEEE 802.5 Token Ring Network
  100.    has been developed which presents a unique problem for BOOTP's
  101.    particular message-transfer paradigm.  This memo also suggests a
  102.    solution for this problem.
  103.  
  104.    NOTE: Unless otherwise specified in this document or a later
  105.    document, the information and requirements specified througout this
  106.    document also apply to extensions to BOOTP such as the Dynamic Host
  107.    Configuration Protocol (DHCP) [3].
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Wimer                                                           [Page 2]
  115.  
  116. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  117.  
  118.  
  119. 1.1 Requirements
  120.  
  121.    In this memo, the words that are used to define the significance of
  122.    particular requirements are capitalized.  These words are:
  123.  
  124.       o "MUST"
  125.  
  126.         This word or the adjective "REQUIRED" means that the item
  127.         is an absolute requirement of the specification.
  128.  
  129.       o "MUST NOT"
  130.  
  131.         This phrase means that the item is an absolute prohibition
  132.         of the specification.
  133.  
  134.       o "SHOULD"
  135.  
  136.         This word or the adjective "RECOMMENDED" means that there
  137.         may exist valid reasons in particular circumstances to
  138.         ignore this item, but the full implications should be
  139.         understood and the case carefully weighed before choosing a
  140.         different course.
  141.  
  142.       o "SHOULD NOT"
  143.  
  144.         This phrase means that there may exist valid reasons in
  145.         particular circumstances when the listed behavior is
  146.         acceptable or even useful, but the full implications should
  147.         be understood and the case carefully weighed before
  148.         implementing any behavior described with this label.
  149.  
  150.       o "MAY"
  151.  
  152.         This word or the adjective "OPTIONAL" means that this item
  153.         is truly optional.  One vendor may choose to include the
  154.         item because a particular marketplace requires it or
  155.         because it enhances the product, for example; another
  156.         vendor may omit the same item.
  157.  
  158. 1.2 Terminology
  159.  
  160.    This memo uses the following terms:
  161.  
  162.       BOOTREQUEST
  163.  
  164.          A BOOTREQUEST message is a BOOTP message sent from a BOOTP
  165.          client to a BOOTP server, requesting configuration information.
  166.  
  167.  
  168.  
  169.  
  170. Wimer                                                           [Page 3]
  171.  
  172. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  173.  
  174.  
  175.       BOOTREPLY
  176.  
  177.          A BOOTREPLY message is a BOOTP message sent from a BOOTP server
  178.          to a BOOTP client, providing configuration information.
  179.  
  180.       Silently discard
  181.  
  182.          This memo specifies several cases where a BOOTP entity is to
  183.          "silently discard" a received BOOTP message.  This means that
  184.          the entity is to discard the message without further
  185.          processing, and that the entity will not send any ICMP error
  186.          message as a result.  However, for diagnosis of problems, the
  187.          entity SHOULD provide the capability of logging the error,
  188.          including the contents of the silently-discarded message, and
  189.          SHOULD record the event in a statistics counter.
  190.  
  191. 1.3 Data Transmission Order
  192.  
  193.    The order of transmission of the header and data described in this
  194.    document is resolved to the octet level.  Whenever a diagram shows a
  195.    group of octets, the order of transmission of those octets is the
  196.    normal order in which they are read in English.  For example, in the
  197.    following diagram, the octets are transmitted in the order they are
  198.    numbered.
  199.  
  200.                      0                   1
  201.                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  202.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  203.                      |       1       |       2       |
  204.                      +-------------------------------+
  205.                      |       3       |       4       |
  206.                      +-------------------------------+
  207.                      |       5       |       6       |
  208.                      +-------------------------------+
  209.  
  210.    Whenever an octet represents a numeric quantity, the leftmost bit in
  211.    the diagram is the high order or most significant bit.  That is, the
  212.    bit labeled 0 is the most significant bit.  For example, the
  213.    following diagram represents the value 170 (decimal).
  214.  
  215.                                0 1 2 3 4 5 6 7
  216.                               +-+-+-+-+-+-+-+-+
  217.                               |1 0 1 0 1 0 1 0|
  218.                               +---------------+
  219.  
  220.    Similarly, whenever a multi-octet field represents a numeric quantity
  221.    the leftmost bit of the whole field is the most significant bit.
  222.    When a multi-octet quantity is transmitted the most significant octet
  223.  
  224.  
  225.  
  226. Wimer                                                           [Page 4]
  227.  
  228. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  229.  
  230.  
  231.    is transmitted first.
  232.  
  233. 2. General Issues
  234.  
  235.    This section covers issues of general relevance to all BOOTP entities
  236.    (clients, servers, and relay agents).
  237.  
  238. 2.1 General BOOTP Processing
  239.  
  240.    The following consistency checks SHOULD be performed on BOOTP
  241.    messages:
  242.  
  243.       o The IP Total Length and UDP Length must be large enough to
  244.         contain the minimal BOOTP header of 300 octets (in the UDP
  245.         data field) specified in [1].
  246.  
  247.    NOTE: Future extensions to the BOOTP protocol may increase the size
  248.    of BOOTP messages.  Therefore, BOOTP messages which, according to the
  249.    IP Total Length and UDP Length fields, are larger than the minimum
  250.    size specified by [1] MUST also be accepted.
  251.  
  252.       o The 'op' (opcode) field of the message must contain either the
  253.         code for a BOOTREQUEST (1) or the code for a BOOTREPLY (2).
  254.  
  255.    BOOTP messages not meeting these consistency checks MUST be silently
  256.    discarded.
  257.  
  258. 2.2 Definition of the 'flags' Field
  259.  
  260.    The standard BOOTP message format defined in [1] includes a two-octet
  261.    field located between the 'secs' field and the 'ciaddr' field.  This
  262.    field is merely designated as "unused" and its contents left
  263.    unspecified, although Section 7.1 of [1] does offer the following
  264.    suggestion:
  265.  
  266.       "Before setting up the packet for the first time, it is a good
  267.       idea to clear the entire packet buffer to all zeros; this will
  268.       place all fields in their default state."
  269.  
  270.       This memo hereby designates this two-octet field as the 'flags'
  271.       field.
  272.  
  273.       This memo hereby defines the most significant bit of the 'flags'
  274.       field as the BROADCAST (B) flag.  The semantics of this flag are
  275.       discussed in Sections 3.1.1 and 4.1.2 of this memo.
  276.  
  277.       The remaining bits of the 'flags' field are reserved for future
  278.       use.  They MUST be set to zero by clients and ignored by servers
  279.  
  280.  
  281.  
  282. Wimer                                                           [Page 5]
  283.  
  284. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  285.  
  286.  
  287.       and relay agents.
  288.  
  289.       The 'flags' field, then, appears as follows:
  290.  
  291.                      0                   1
  292.                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  293.                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  294.                      |B|             MBZ             |
  295.                      +-+-----------------------------+
  296.  
  297.    where:
  298.  
  299.       B    BROADCAST flag (discussed in Sections 3.1.1 and 4.1.2)
  300.  
  301.       MBZ  MUST BE ZERO (reserved for future use)
  302.  
  303.    The format of a BOOTP message is shown below.  The numbers in
  304.    parentheses indicate the size of each field in octets.
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Wimer                                                           [Page 6]
  339.  
  340. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  341.  
  342.  
  343.    0                   1                   2                   3
  344.    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  345.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  346.    |     op (1)    |   htype (1)   |   hlen (1)    |   hops (1)    |
  347.    +---------------+---------------+---------------+---------------+
  348.    |                            xid (4)                            |
  349.    +-------------------------------+-------------------------------+
  350.    |           secs (2)            |           flags (2)           |
  351.    +-------------------------------+-------------------------------+
  352.    |                           ciaddr (4)                          |
  353.    +---------------------------------------------------------------+
  354.    |                           yiaddr (4)                          |
  355.    +---------------------------------------------------------------+
  356.    |                           siaddr (4)                          |
  357.    +---------------------------------------------------------------+
  358.    |                           giaddr (4)                          |
  359.    +---------------------------------------------------------------+
  360.    |                                                               |
  361.    |                           chaddr (16)                         |
  362.    |                                                               |
  363.    |                                                               |
  364.    +---------------------------------------------------------------+
  365.    |                                                               |
  366.    |                           sname  (64)                         |
  367.    +---------------------------------------------------------------+
  368.    |                                                               |
  369.    |                           file   (128)                        |
  370.    +---------------------------------------------------------------+
  371.    |                                                               |
  372.    |                           vend   (64)                         |
  373.    +---------------------------------------------------------------+
  374.  
  375. 2.3 Bit Ordering of Hardware Addresses
  376.  
  377.    The bit ordering used for link-level hardware addresses in the
  378.    'chaddr' field SHOULD be the same as the ordering used for the ARP
  379.    protocol [4] on the client's link-level network (assuming ARP is
  380.    defined for that network).
  381.  
  382.    The 'chaddr' field MUST be preserved as it was specified by the BOOTP
  383.    client.  A relay agent MUST NOT reverse the bit ordering of the
  384.    'chaddr' field even if it happens to be relaying a BOOTREQUEST
  385.    between two networks which use different bit orderings.
  386.  
  387.       DISCUSSION:
  388.  
  389.          One of the primary reasons the 'chaddr' field exists is to
  390.          enable BOOTP servers and relay agents to communicate directly
  391.  
  392.  
  393.  
  394. Wimer                                                           [Page 7]
  395.  
  396. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  397.  
  398.  
  399.          with clients without the use of broadcasts.  In practice, the
  400.          contents of the 'chaddr' field is often used to create an ARP-
  401.          cache entry in exactly the same way the normal ARP protocol
  402.          would have.  Clearly, interoperability can only be achieved if
  403.          a consistent interpretation of the 'chaddr' field is used.
  404.  
  405.          As a practical example, this means that the bit ordering used
  406.          for the 'chaddr' field by a BOOTP client on an IEEE 802.5 Token
  407.          Ring network is the opposite of the bit ordering used by a
  408.          BOOTP client on a DIX ethernet network.
  409.  
  410. 2.4 BOOTP Over IEEE 802.5 Token Ring Networks
  411.  
  412.    Special consideration of the client/server and client/relay agent
  413.    interactions must be given to IEEE 802.5 networks because of non-
  414.    transparent bridging.
  415.  
  416.    The client SHOULD send its broadcast BOOTREQUEST with an All Routes
  417.    Explorer RIF.  This will enable servers/relay agents to cache the
  418.    return route if they choose to do so.  For those server/relay agents
  419.    which cannot cache the return route (because they are stateless, for
  420.    example), the BOOTREPLY message SHOULD be sent to the client's
  421.    hardware address, as taken from the BOOTP message, with a Spanning
  422.    Tree Rooted RIF.  The actual bridge route will be recorded by the
  423.    client and server/relay agent by normal ARP processing code.
  424.  
  425.       DISCUSSION:
  426.  
  427.          In the simplest case, an unbridged, single ring network, the
  428.          broadcast behavior of the BOOTP protocol is identical to that
  429.          of Ethernet networks.  However, a BOOTP client cannot know, a
  430.          priori, that an 802.5 network is not bridged.  In fact, the
  431.          likelihood is that the server, or relay agent, will not know
  432.          either.
  433.  
  434.          Of the four possible scenerios, only two are interesting: where
  435.          the assumption is that the 802.5 network is not bridged and it
  436.          is, and the assumption that the network is bridged and it is
  437.          not.  In the former case, the Routing Information Field (RIF)
  438.          will not be used; therefore, if the server/relay agent are on
  439.          another segment of the ring, the client cannot reach it.  In
  440.          the latter case, the RIF field will be used, resulting in a few
  441.          extraneous bytes on the ring.  It is obvious that an almost
  442.          immeasurable inefficiency is to be preferred over a complete
  443.          failure to communicate.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Wimer                                                           [Page 8]
  451.  
  452. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  453.  
  454.  
  455.          Given that the assumption is that RIF fields will be needed, it
  456.          is necesary to determine the optimum method for the client to
  457.          reach the server/relay agent, and the optimum method for the
  458.          response to be returned.
  459.  
  460. 3. BOOTP Client Behavior
  461.  
  462.    This section clarifies various issues regarding BOOTP client
  463.    behavior.
  464.  
  465. 3.1 Client use of the 'flags' field
  466.  
  467. 3.1.1 The BROADCAST flag
  468.  
  469.    Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
  470.    messages directly to a client using unicast delivery.  The IP
  471.    destination address (in the IP header) is set to the BOOTP 'yiaddr'
  472.    address and the link-layer destination address is set to the BOOTP
  473.    'chaddr' address.  Unfortunately, some client implementations are
  474.    unable to receive such unicast IP datagrams until they know their own
  475.    IP address (thus we have a "chicken and egg" issue).  Often, however,
  476.    they can receive broadcast IP datagrams (those with a valid IP
  477.    broadcast address as the IP destination and the link-layer broadcast
  478.    address as the link-layer destination).
  479.  
  480.    If a client falls into this category, it SHOULD set (to 1) the
  481.    newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
  482.    messages it generates.  This will provide a hint to BOOTP servers and
  483.    relay agents that they should attempt to broadcast their BOOTREPLY
  484.    messages to the client.
  485.  
  486.    If a client does not have this limitation (i.e., it is perfectly able
  487.    to receive unicast BOOTREPLY messages), it SHOULD NOT set the
  488.    BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).
  489.  
  490.       DISCUSSION:
  491.  
  492.          This addition to the protocol is a workaround for old host
  493.          implementations.  Such implementations SHOULD be modified so
  494.          that they may receive unicast BOOTREPLY messages, thus making
  495.          use of this workaround unnecessary.  In general, the use of
  496.          this mechanism is discouraged.
  497.  
  498. 3.1.2 The remainder of the 'flags' field
  499.  
  500.    The remaining bits of the 'flags' field are reserved for future use.
  501.    A client MUST set these bits to zero in all BOOTREQUEST messages it
  502.    generates.  A client MUST ignore these bits in all BOOTREPLY messages
  503.  
  504.  
  505.  
  506. Wimer                                                           [Page 9]
  507.  
  508. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  509.  
  510.  
  511.    it receives.
  512.  
  513. 3.2 Definition of the 'secs' field
  514.  
  515.    The 'secs' field of a BOOTREQUEST message SHOULD represent the
  516.    elapsed time, in seconds, since the client sent its first BOOTREQUEST
  517.    message.  Note that this implies that the 'secs' field of the first
  518.    BOOTREQUEST message SHOULD be set to zero.
  519.  
  520.    Clients SHOULD NOT set the 'secs' field to a value which is constant
  521.    for all BOOTREQUEST messages.
  522.  
  523.       DISCUSSION:
  524.  
  525.          The original definition of the 'secs' field was vague.  It was
  526.          not clear whether it represented the time since the first
  527.          BOOTREQUEST message was sent or some other time period such as
  528.          the time since the client machine was powered-up.  This has
  529.          limited its usefulness as a policy control mechanism for BOOTP
  530.          servers and relay agents.  Furthermore, certain client
  531.          implementations have been known to simply set this field to a
  532.          constant value or use incorrect byte-ordering.  Incorrect
  533.          byte-ordering usually makes it appear as if a client has been
  534.          waiting much longer than it really has, so a relay agent will
  535.          relay the BOOTREQUEST sooner than desired (usually
  536.          immediately).  These implementation errors have further
  537.          undermined the usefulness of the 'secs' field.  These incorrect
  538.          implementations SHOULD be corrected.
  539.  
  540. 3.3 Use of the 'ciaddr' and 'yiaddr' fields
  541.  
  542.    If a BOOTP client does not know what IP address it should be using,
  543.    the client SHOULD set the 'ciaddr' field to 0.0.0.0.  If the client
  544.    has the ability to remember the last IP address it was assigned, or
  545.    it has been preconfigured with an IP address via some alternate
  546.    mechanism, the client MAY fill the 'ciaddr' field with that IP
  547.    address.  If the client does place a non-zero IP address in the
  548.    'ciaddr' field, the client MUST be prepared to accept incoming
  549.    unicast datagrams addressed to that IP address and also answer ARP
  550.    requests for that IP address (if ARP is used on that network).
  551.  
  552.    The BOOTP server is free to assign a different IP address (in the
  553.    'yiaddr' field) than the client expressed in 'ciaddr'.  The client
  554.    SHOULD adopt the IP address specified in 'yiaddr' and begin using it
  555.    as soon as possible.
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Wimer                                                          [Page 10]
  563.  
  564. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  565.  
  566.  
  567.       DISCUSSION:
  568.  
  569.          There are various interpretations about the purpose of the
  570.          'ciaddr' field and, unfortunately, no agreement on a single
  571.          correct interpretation.  One interpretation is that if a client
  572.          is willing to accept whatever IP address the BOOTP server
  573.          assigns to it, the client should always place 0.0.0.0 in the
  574.          'ciaddr' field, regardless of whether it knows its previously-
  575.          assigned address.  Conversely, if the client wishes to assert
  576.          that it must have a particular IP address (e.g., the IP address
  577.          was hand-configured by the host administrator and BOOTP is only
  578.          being used to obtain a boot file and/or information from the
  579.          'vend' field), the client will then fill the 'ciaddr' field
  580.          with the desired IP address and ignore the IP address assigned
  581.          by the BOOTP server as indicated in the 'yiaddr' field.  An
  582.          alternate interpretation holds that the client always fills the
  583.          'ciaddr' field with its most recently-assigned IP address (if
  584.          known) even if that address may be incorrect.  Such a client
  585.          will still accept and use the address assigned by the BOOTP
  586.          server as indicated in the 'yiaddr' field.  The motivation for
  587.          this interpretation is to aid the server in identifying the
  588.          client and/or in delivering the BOOTREPLY to the client.  Yet a
  589.          third (mis)interpretation allows the client to use 'ciaddr' to
  590.          express the client's desired IP address, even if the client has
  591.          never used that address before or is not currently using that
  592.          address.
  593.  
  594.          The last interpretation is incorrect as it may prevent the
  595.          BOOTREPLY from reaching the client.  The server will usually
  596.          unicast the reply to the address given in 'ciaddr' but the
  597.          client may not be listening on that address yet, or the client
  598.          may be connected to an incorrect subnet such that normal IP
  599.          routing (correctly) routes the reply to a different subnet.
  600.  
  601.          The second interpretation also suffers from the "incorrect
  602.          subnet" problem.
  603.  
  604.          The first interpretation seems to be the safest and most likely
  605.          to promote interoperability.
  606.  
  607. 3.4 Interpretation of the 'giaddr' field
  608.  
  609.    The 'giaddr' field is rather poorly named.  It exists to facilitate
  610.    the transfer of BOOTREQUEST messages from a client, through BOOTP
  611.    relay agents, to servers on different networks than the client.
  612.    Similarly, it facilitates the delivery of BOOTREPLY messages from the
  613.    servers, through BOOTP relay agents, back to the client.  In no case
  614.    does it represent a general IP router to be used by the client.  A
  615.  
  616.  
  617.  
  618. Wimer                                                          [Page 11]
  619.  
  620. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  621.  
  622.  
  623.    BOOTP client MUST set the 'giaddr' field to zero (0.0.0.0) in all
  624.    BOOTREQUEST messages it generates.
  625.  
  626.    A BOOTP client MUST NOT interpret the 'giaddr' field of a BOOTREPLY
  627.    message to be the IP address of an IP router.  A BOOTP client SHOULD
  628.    completely ignore the contents of the 'giaddr' field in BOOTREPLY
  629.    messages.
  630.  
  631.       DISCUSSION:
  632.  
  633.          The semantics of the 'giaddr' field were poorly defined.
  634.          Section 7.5 of [1] states:
  635.  
  636.            "If 'giaddr' (gateway address) is nonzero, then the packets
  637.            should be forwarded there first, in order to get to the
  638.            server."
  639.  
  640.    In that sentence, "get to" refers to communication from the client to
  641.    the server subsequent to the BOOTP exchange, such as a TFTP session.
  642.    Unfortunately, the 'giaddr' field may contain the address of a BOOTP
  643.    relay agent that is not itself an IP router (according to [1],
  644.    Section 8, fifth paragraph), in which case, it will be useless as a
  645.    first-hop for TFTP packets sent to the server (since, by definition,
  646.    non-routers don't forward datagrams at the IP layer).
  647.  
  648.    Although now prohibited by Section 4.1.1 of this memo, the 'giaddr'
  649.    field might contain a broadcast address according to Section 8, sixth
  650.    paragraph of [1].  Not only would such an address be useless as a
  651.    router address, it might also cause the client to ARP for the
  652.    broadcast address (since, if the client didn't receive a subnet mask
  653.    in the BOOTREPLY message, it would be unable to recognize a subnet
  654.    broadcast address).  This is clearly undesirable.
  655.  
  656.    To reach a non-local server, clients can obtain a first-hop router
  657.    address from the "Gateway" subfield of the "Vendor Information
  658.    Extensions" [2] (if present), or via the ICMP router discovery
  659.    protocol [5] or other similar mechanism.
  660.  
  661. 3.5 Vendor information "magic cookie"
  662.  
  663.    It is RECOMMENDED that a BOOTP client always fill the first four
  664.    octets of the 'vend' (vendor information) field of a BOOTREQUEST with
  665.    a four-octet identifier called a "magic cookie."  A BOOTP client
  666.    SHOULD do this even if it has no special information to communicate
  667.    to the BOOTP server using the 'vend' field.  This aids the BOOTP
  668.    server in determining what vendor information format it should use in
  669.    its BOOTREPLY messages.
  670.  
  671.  
  672.  
  673.  
  674. Wimer                                                          [Page 12]
  675.  
  676. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  677.  
  678.  
  679.    If a special vendor-specific magic cookie is not being used, a BOOTP
  680.    client SHOULD use the dotted decimal value 99.130.83.99 as specified
  681.    in [2].  In this case, if the client has no information to
  682.    communicate to the server, the octet immediately following the magic
  683.    cookie SHOULD be set to the "End" tag (255) and the remaining octets
  684.    of the 'vend' field SHOULD be set to zero.
  685.  
  686.       DISCUSSION:
  687.  
  688.          Sometimes different operating systems or networking packages
  689.          are run on the same machine at different times (or even at the
  690.          same time!).  Since the hardware address placed in the 'chaddr'
  691.          field will likely be the same, BOOTREQUESTs from completely
  692.          different BOOTP clients on the same machine will likely be
  693.          difficult for a BOOTP server to differentiate.  If the client
  694.          includes a magic cookie in its BOOTREQUESTs, the server will at
  695.          least know what format the client expects and can understand in
  696.          corresponding BOOTREPLY messages.
  697.  
  698. 4. BOOTP Relay Agents
  699.  
  700.          In many cases, BOOTP clients and their associated BOOTP
  701.          server(s) do not reside on the same IP network or subnet.  In
  702.          such cases, some kind of third-party agent is required to
  703.          transfer BOOTP messages between clients and servers.  Such an
  704.          agent was originally referred to as a "BOOTP forwarding agent."
  705.          However, in order to avoid confusion with the IP forwarding
  706.          function of an IP router, the name "BOOTP relay agent" is
  707.          hereby adopted instead.
  708.  
  709.       DISCUSSION:
  710.  
  711.          A BOOTP relay agent performs a task which is distinct from an
  712.          IP router's normal IP forwarding function.  While a router
  713.          normally switches IP datagrams between networks more-or-less
  714.          transparently, a BOOTP relay agent may more properly be thought
  715.          to receive BOOTP messages as a final destination and then
  716.          generate new BOOTP messages as a result.  It is incorrect for a
  717.          relay agent implementation to simply forward a BOOTP message
  718.          "straight through like a regular packet."
  719.  
  720.          This relay-agent functionality is most conveniently located in
  721.          the routers which interconnect the clients and servers, but may
  722.          alternatively be located in a host which is directly connected
  723.          to the client subnet.
  724.  
  725.          Any Internet host or router which provides BOOTP relay-agent
  726.          capability MUST conform to the specifications in this memo.
  727.  
  728.  
  729.  
  730. Wimer                                                          [Page 13]
  731.  
  732. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  733.  
  734.  
  735. 4.1 General BOOTP Processing for Relay Agents
  736.  
  737.    All locally delivered UDP messages whose UDP destination port number
  738.    is BOOTPS (67) are considered for special processing by the host or
  739.    router's logical BOOTP relay agent.
  740.  
  741.    In the case of a host, locally delivered datagrams are simply all
  742.    datagrams normally received by that host, i.e., broadcast and
  743.    multicast datagrams as well as unicast datagrams addressed to IP
  744.    addresses of that host.
  745.  
  746.    In the case of a router, locally delivered datagrams are broadcast
  747.    and multicast datagrams as well as unicast datagrams addressed to IP
  748.    addresses of that router.  These are datagrams for which the router
  749.    should be considered an end destination as opposed to an intermediate
  750.    switching node.  Thus a unicast datagram with an IP destination not
  751.    matching any of the router's IP addresses is not considered for
  752.    processing by the router's logical BOOTP relay agent.
  753.  
  754.    Hosts and routers are usually required to silently discard incoming
  755.    datagrams containing illegal IP source addresses.  This is generally
  756.    known as "Martian address filtering."  One of these illegal addresses
  757.    is 0.0.0.0 (or actually anything on network 0).  However, hosts or
  758.    routers which support a BOOTP relay agent MUST accept for local
  759.    delivery to the relay agent BOOTREQUEST messages whose IP source
  760.    address is 0.0.0.0.  BOOTREQUEST messages from legal IP source
  761.    addresses MUST also be accepted.
  762.  
  763.    A relay agent MUST silently discard any received UDP messages whose
  764.    UDP destination port number is BOOTPC (68).
  765.  
  766.       DISCUSSION:
  767.  
  768.          There should be no need for a relay agent to process messages
  769.          addressed to the BOOTPC port.  Careful reading of the original
  770.          BOOTP specification [1] will show this.  Nevertheless, some
  771.          relay agent implementations incorrectly relay such messages.
  772.  
  773.    The consistency checks specified in Section 2.1 SHOULD be performed
  774.    by the relay agent.  BOOTP messages not meeting these consistency
  775.    checks MUST be silently discarded.
  776.  
  777. 4.1.1 BOOTREQUEST Messages
  778.  
  779.    Some configuration mechanism MUST exist to enable or disable the
  780.    relaying of BOOTREQUEST messages.  Relaying MUST be disabled by
  781.    default.
  782.  
  783.  
  784.  
  785.  
  786. Wimer                                                          [Page 14]
  787.  
  788. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  789.  
  790.  
  791.    When the BOOTP relay agent receives a BOOTREQUEST message, it MAY use
  792.    the value of the 'secs' (seconds since client began booting) field of
  793.    the request as a factor in deciding whether to relay the request.  If
  794.    such a policy mechanism is implemented, its threshold SHOULD be
  795.    configurable.
  796.  
  797.       DISCUSSION:
  798.  
  799.          To date, this feature of the BOOTP protocol has not necessarily
  800.          been shown to be useful.  See Section 3.2 for a discussion.
  801.  
  802.    The relay agent MUST silently discard BOOTREQUEST messages whose
  803.    'hops' field exceeds the value 16.  A configuration option SHOULD be
  804.    provided to set this threshold to a smaller value if desired by the
  805.    network manager.  The default setting for a configurable threshold
  806.    SHOULD be 4.
  807.  
  808.    If the relay agent does decide to relay the request, it MUST examine
  809.    the 'giaddr' ("gateway" IP address) field.  If this field is zero,
  810.    the relay agent MUST fill this field with the IP address of the
  811.    interface on which the request was received.  If the interface has
  812.    more than one IP address logically associated with it, the relay
  813.    agent SHOULD choose one IP address associated with that interface and
  814.    use it consistently for all BOOTP messages it relays.  If the
  815.    'giaddr' field contains some non-zero value, the 'giaddr' field MUST
  816.    NOT be modified.  The relay agent MUST NOT, under any circumstances,
  817.    fill the 'giaddr' field with a broadcast address as is suggested in
  818.    [1] (Section 8, sixth paragraph).
  819.  
  820.    The value of the 'hops' field MUST be incremented.
  821.  
  822.    All other BOOTP fields MUST be preserved intact.
  823.  
  824.    At this point, the request is relayed to its new destination (or
  825.    destinations).  This destination MUST be configurable.  Further, this
  826.    destination configuration SHOULD be independent of the destination
  827.    configuration for any other so-called "broadcast forwarders" (e.g.,
  828.    for the UDP-based TFTP, DNS, Time, etc.  protocols).
  829.  
  830.       DISCUSSION:
  831.  
  832.          The network manager may wish the relaying destination to be an
  833.          IP unicast, multicast, broadcast, or some combination.  A
  834.          configurable list of destination IP addresses provides good
  835.          flexibility.  More flexible configuration schemes are
  836.          encouraged.  For example, it may be desirable to send to the
  837.          limited broadcast address (255.255.255.255) on specific
  838.          physical interfaces.  However, if the BOOTREQUEST message was
  839.  
  840.  
  841.  
  842. Wimer                                                          [Page 15]
  843.  
  844. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  845.  
  846.  
  847.          received as a broadcast, the relay agent MUST NOT rebroadcast
  848.          the BOOTREQUEST on the physical interface from whence it came.
  849.  
  850.          A relay agent MUST use the same destination (or set of
  851.          destinations) for all BOOTREQUEST messages it relays from a
  852.          given client.
  853.  
  854.       DISCUSSION:
  855.  
  856.          At least one known relay agent implementation uses a round-
  857.          robin scheme to provide load balancing across multiple BOOTP
  858.          servers.  Each time it receives a new BOOTREQUEST message, it
  859.          relays the message to the next BOOTP server in a list of
  860.          servers.  Thus, with this relay agent, multiple consecutive
  861.          BOOTREQUEST messages from a given client will be delivered to
  862.          different servers.
  863.  
  864.          Unfortunately, this well-intentioned scheme reacts badly with
  865.          DHCP [3] and perhaps other variations of the BOOTP protocol
  866.          which depend on multiple exchanges of BOOTREQUEST and BOOTREPLY
  867.          messages between clients and servers.  Therefore, all
  868.          BOOTREQUEST messages from a given client MUST be relayed to the
  869.          same destination (or set of destinations).
  870.  
  871.          One way to meet this requirement while providing some load-
  872.          balancing benefit is to hash the client's link-layer address
  873.          (or some other reliable client-identifying information) and use
  874.          the resulting hash value to select the appropriate relay
  875.          destination (or set of destinations).  The simplest solution,
  876.          of course, is to not use a load-balancing scheme and just relay
  877.          ALL received BOOTREQUEST messages to the same destination (or
  878.          set of destinations).
  879.  
  880.          When transmitting the request to its next destination, the
  881.          relay agent may set the IP Time-To-Live field to either the
  882.          default value for new datagrams originated by the relay agent,
  883.          or to the TTL of the original BOOTREQUEST decremented by (at
  884.          least) one.
  885.  
  886.       DISCUSSION:
  887.  
  888.          As an extra precaution against BOOTREQUEST loops, it is
  889.          preferable to use the decremented TTL from the original
  890.          BOOTREQUEST.  Unfortunately, this may be difficult to do in
  891.          some implementations.
  892.  
  893.          If the BOOTREQUEST has a UDP checksum (i.e., the UDP checksum
  894.          is non-zero), the checksum must be recalculated before
  895.  
  896.  
  897.  
  898. Wimer                                                          [Page 16]
  899.  
  900. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  901.  
  902.  
  903.          transmitting the request.
  904.  
  905. 4.1.2 BOOTREPLY Messages
  906.  
  907.    BOOTP relay agents relay BOOTREPLY messages only to BOOTP clients.
  908.    It is the responsibility of BOOTP servers to send BOOTREPLY messages
  909.    directly to the relay agent identified in the 'giaddr' field.
  910.    Therefore, a relay agent may assume that all BOOTREPLY messages it
  911.    receives are intended for BOOTP clients on its directly-connected
  912.    networks.
  913.  
  914.    When a relay agent receives a BOOTREPLY message, it should examine
  915.    the BOOTP 'giaddr', 'yiaddr', 'chaddr', 'htype', and 'hlen' fields.
  916.    These fields should provide adequate information for the relay agent
  917.    to deliver the BOOTREPLY message to the client.
  918.  
  919.    The 'giaddr' field can be used to identify the logical interface from
  920.    which the reply must be sent (i.e., the host or router interface
  921.    connected to the same network as the BOOTP client).  If the content
  922.    of the 'giaddr' field does not match one of the relay agent's
  923.    directly-connected logical interfaces, the BOOTREPLY messsage MUST be
  924.    silently discarded.
  925.  
  926.    The 'htype', 'hlen', and 'chaddr' fields supply the link-layer
  927.    hardware type, hardware address length, and hardware address of the
  928.    client as defined in the ARP protocol [4] and the Assigned Numbers
  929.    document [6].  The 'yiaddr' field is the IP address of the client, as
  930.    assigned by the BOOTP server.
  931.  
  932.    The relay agent SHOULD examine the newly-defined BROADCAST flag (see
  933.    Sections 2.2 and 3.1.1 for more information).  If this flag is set to
  934.    1, the reply SHOULD be sent as an IP broadcast using the IP limited
  935.    broadcast address 255.255.255.255 as the IP destination address and
  936.    the link-layer broadcast address as the link-layer destination
  937.    address.  If the BROADCAST flag is cleared (0), the reply SHOULD be
  938.    sent as an IP unicast to the IP address specified by the 'yiaddr'
  939.    field and the link-layer address specified in the 'chaddr' field.  If
  940.    unicasting is not possible, the reply MAY be sent as a broadcast, in
  941.    which case it SHOULD be sent to the link-layer broadcast address
  942.    using the IP limited broadcast address 255.255.255.255 as the IP
  943.    destination address.
  944.  
  945.       DISCUSSION:
  946.  
  947.          The addition of the BROADCAST flag to the protocol is a
  948.          workaround to help promote interoperability with certain client
  949.          implementations.
  950.  
  951.  
  952.  
  953.  
  954. Wimer                                                          [Page 17]
  955.  
  956. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  957.  
  958.  
  959.          Note that since the 'flags' field was previously defined in [1]
  960.          simply as an "unused" field, it is possible that old client or
  961.          server implementations may accidentally and unknowingly set the
  962.          new BROADCAST flag.  It is actually expected that such
  963.          implementations will be rare (most implementations seem to
  964.          zero-out this field), but interactions with such
  965.          implementations must nevertheless be considered.  If an old
  966.          client or server does set the BROADCAST flag to 1 incorrectly,
  967.          conforming relay agents will generate broadcast BOOTREPLY
  968.          messages to the corresponding client.  The BOOTREPLY messages
  969.          should still properly reach the client, at the cost of one
  970.          (otherwise unnecessary) additional broadcast.  This, however,
  971.          is no worse than a server or relay agent which always
  972.          broadcasts its BOOTREPLY messages.
  973.  
  974.          Older client or server implementations which accidentally set
  975.          the BROADCAST flag SHOULD be corrected to properly comply with
  976.          this newer specification.
  977.  
  978.          All BOOTP fields MUST be preserved intact.  The relay agent
  979.          MUST NOT modify any BOOTP field of the BOOTREPLY message when
  980.          relaying it to the client.
  981.  
  982.          The reply MUST have its UDP destination port set to BOOTPC
  983.          (68).
  984.  
  985.          If the BOOTREPLY has a UDP checksum (i.e., the UDP checksum is
  986.          non-zero), the checksum must be recalculated before
  987.          transmitting the reply.
  988.  
  989. 5. BOOTP Server Behavior
  990.  
  991.    This section provides clarifications on the behavior of BOOTP
  992.    servers.
  993.  
  994. 5.1 Reception of BOOTREQUEST Messages
  995.  
  996.    All received UDP messages whose UDP destination port number is BOOTPS
  997.    (67) are considered for processing by the BOOTP server.
  998.  
  999.    Hosts and routers are usually required to silently discard incoming
  1000.    datagrams containing illegal IP source addresses.  This is generally
  1001.    known as "Martian address filtering."  One of these illegal addresses
  1002.    is 0.0.0.0 (or actually anything on network 0).  However, hosts or
  1003.    routers which support a BOOTP server MUST accept for local delivery
  1004.    to the server BOOTREQUEST messages whose IP source address is
  1005.    0.0.0.0.  BOOTREQUEST messages from legal IP source addresses MUST
  1006.    also be accepted.
  1007.  
  1008.  
  1009.  
  1010. Wimer                                                          [Page 18]
  1011.  
  1012. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  1013.  
  1014.  
  1015.    A BOOTP server MUST silently discard any received UDP messages whose
  1016.    UDP destination port number is BOOTPC (68).
  1017.  
  1018.       DISCUSSION:
  1019.  
  1020.          There should be no need for a BOOTP server to process messages
  1021.          addressed to the BOOTPC port.  Careful reading of the original
  1022.          BOOTP specification [1] will show this.
  1023.  
  1024.          The consistency checks specified in Section 2.1 SHOULD be
  1025.          performed by the BOOTP server.  BOOTP messages not meeting
  1026.          these consistency checks MUST be silently discarded.
  1027.  
  1028. 5.2 Use of the 'secs' field
  1029.  
  1030.    When the BOOTP server receives a BOOTREQUEST message, it MAY use the
  1031.    value of the 'secs' (seconds since client began booting) field of the
  1032.    request as a factor in deciding whether and/or how to reply to the
  1033.    request.
  1034.  
  1035.       DISCUSSION:
  1036.  
  1037.          To date, this feature of the BOOTP protocol has not necessarily
  1038.          been shown to be useful.  See Section 3.2 for a discussion.
  1039.  
  1040. 5.3 Use of the 'ciaddr' field
  1041.  
  1042.    There have been various client interpretations of the 'ciaddr' field
  1043.    for which Section 3.3 should be consulted.  A BOOTP server SHOULD be
  1044.    prepared to deal with these varying interpretations.  In general, the
  1045.    'ciaddr' field SHOULD NOT be trusted as a sole key in identifying a
  1046.    client; the contents of the 'ciaddr', 'chaddr', 'htype', and 'hlen'
  1047.    fields, and probably other information (perhaps in the 'file' and
  1048.    'vend' fields) SHOULD all be considered together in deciding how to
  1049.    respond to a given client.
  1050.  
  1051.    BOOTP servers SHOULD preserve the contents of the 'ciaddr' field in
  1052.    BOOTREPLY messages; the contents of 'ciaddr' in a BOOTREPLY message
  1053.    SHOULD exactly match the contents of 'ciaddr' in the corresponding
  1054.    BOOTREQUEST message.
  1055.  
  1056.       DISCUSSION:
  1057.  
  1058.          It has been suggested that a client may wish to use the
  1059.          contents of 'ciaddr' to further verify that a particular
  1060.          BOOTREPLY message was indeed intended for it.
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Wimer                                                          [Page 19]
  1067.  
  1068. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  1069.  
  1070.  
  1071. 5.4 Strategy for Delivery of BOOTREPLY Messages
  1072.  
  1073.    Once the BOOTP server has created an appropriate BOOTREPLY message,
  1074.    that BOOTREPLY message must be properly delivered to the client.
  1075.  
  1076.    The server SHOULD first check the 'ciaddr' field.  If the 'ciaddr'
  1077.    field is non-zero, the BOOTREPLY message SHOULD be sent as an IP
  1078.    unicast to the IP address identified in the 'ciaddr' field.  The UDP
  1079.    destination port MUST be set to BOOTPC (68).  However, the server
  1080.    MUST be aware of the problems identified in Section 3.3.  The server
  1081.    MAY choose to ignore the 'ciaddr' field and act as if the 'ciaddr'
  1082.    field contains 0.0.0.0 (and thus continue with the rest of the
  1083.    delivery algorithm below).
  1084.  
  1085.    The server SHOULD next check the 'giaddr' field.  If this field is
  1086.    non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to
  1087.    the IP address identified in the 'giaddr' field.  The UDP destination
  1088.    port MUST be set to BOOTPS (67).  This action will deliver the
  1089.    BOOTREPLY message directly to the BOOTP relay agent closest to the
  1090.    client; the relay agent will then perform the final delivery to the
  1091.    client.  If the BOOTP server has prior knowledge that a particular
  1092.    client cannot receive unicast BOOTREPLY messages (e.g., the network
  1093.    manager has explicitly configured the server with such knowledge),
  1094.    the server MAY set the newly-defined BROADCAST flag to indicate that
  1095.    relay agents SHOULD broadcast the BOOTREPLY message to the client.
  1096.    Otherwise, the server MUST preserve the state of the BROADCAST flag
  1097.    so that the relay agent can correctly act upon it.
  1098.  
  1099.    If the 'giaddr' field is set to 0.0.0.0, then the client resides on
  1100.    one of the same networks as the BOOTP server.  The server SHOULD
  1101.    examine the newly-defined BROADCAST flag (see Sections 2.2, 3.1.1 and
  1102.    4.1.2 for more information).  If this flag is set to 1 or the server
  1103.    has prior knowledge that the client is unable to receive unicast
  1104.    BOOTREPLY messages, the reply SHOULD be sent as an IP broadcast using
  1105.    the IP limited broadcast address 255.255.255.255 as the IP
  1106.    destination address and the link-layer broadcast address as the
  1107.    link-layer destination address.  If the BROADCAST flag is cleared
  1108.    (0), the reply SHOULD be sent as an IP unicast to the IP address
  1109.    specified by the 'yiaddr' field and the link-layer address specified
  1110.    in the 'chaddr' field.  If unicasting is not possible, the reply MAY
  1111.    be sent as a broadcast in which case it SHOULD be sent to the link-
  1112.    layer broadcast address using the IP limited broadcast address
  1113.    255.255.255.255 as the IP destination address.  In any case, the UDP
  1114.    destination port MUST be set to BOOTPC (68).
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Wimer                                                          [Page 20]
  1123.  
  1124. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  1125.  
  1126.  
  1127.       DISCUSSION:
  1128.  
  1129.          The addition of the BROADCAST flag to the protocol is a
  1130.          workaround to help promote interoperability with certain client
  1131.          implementations.
  1132.  
  1133.          The following table summarizes server delivery decisions for
  1134.          BOOTREPLY messages based upon information in BOOTREQUEST
  1135.          messages:
  1136.  
  1137.       BOOTREQUEST fields     BOOTREPLY values for UDP, IP, link-layer
  1138.    +-----------------------+-----------------------------------------+
  1139.    | 'ciaddr'  'giaddr'  B | UDP dest     IP destination   link dest |
  1140.    +-----------------------+-----------------------------------------+
  1141.    | non-zero     X      X | BOOTPC (68)  'ciaddr'         normal    |
  1142.    | 0.0.0.0   non-zero  X | BOOTPS (67)  'giaddr'         normal    |
  1143.    | 0.0.0.0   0.0.0.0   0 | BOOTPC (68)  'yiaddr'         'chaddr'  |
  1144.    | 0.0.0.0   0.0.0.0   1 | BOOTPC (68)  255.255.255.255  broadcast |
  1145.    +-----------------------+-----------------------------------------+
  1146.  
  1147.         B = BROADCAST flag
  1148.  
  1149.         X = Don't care
  1150.  
  1151.    normal = determine from the given IP destination using normal
  1152.             IP routing mechanisms and/or ARP as for any other
  1153.             normal datagram
  1154.  
  1155. Acknowledgements
  1156.  
  1157.    The author would like to thank Gary Malkin for his contribution of
  1158.    the "BOOTP over IEEE 802.5 Token Ring Networks" section, and Steve
  1159.    Deering for his observations on the problems associated with the
  1160.    'giaddr' field.
  1161.  
  1162.    Ralph Droms and the many members of the IETF Dynamic Host
  1163.    Configuration and Router Requirements working groups provided ideas
  1164.    for this memo as well as encouragement to write it.
  1165.  
  1166.    Philip Almquist and David Piscitello offered many helpful suggestions
  1167.    for improving the clarity, accuracy, and organization of this memo.
  1168.    These contributions are graciously acknowledged.
  1169.  
  1170.  
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Wimer                                                          [Page 21]
  1179.  
  1180. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  1181.  
  1182.  
  1183. References
  1184.  
  1185.    [1] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
  1186.        Stanford University and Sun Microsystems, September 1985.
  1187.  
  1188.    [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
  1189.        USC/Information Sciences Institute, August 1993.  This RFC is
  1190.        occasionally reissued with a new number.  Please be sure to
  1191.        consult the latest version.
  1192.  
  1193.    [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541,
  1194.        Bucknell University, October 1993.
  1195.  
  1196.    [4] Plummer, D., "An Ethernet Address Resolution Protocol", STD 37,
  1197.        RFC 826, MIT, November 1982.
  1198.  
  1199.    [5] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
  1200.        PARC, September 1991.
  1201.  
  1202.    [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  1203.        USC/Information Sciences Institute, July, 1992.  This RFC is
  1204.        periodically reissued with a new number.  Please be sure to
  1205.        consult the latest version.
  1206.  
  1207.  
  1208.  
  1209.  
  1210.  
  1211.  
  1212.  
  1213.  
  1214.  
  1215.  
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233.  
  1234. Wimer                                                          [Page 22]
  1235.  
  1236. RFC 1542        Clarifications and Extensions for BOOTP     October 1993
  1237.  
  1238.  
  1239. Security Considerations
  1240.  
  1241.    There are many factors which make BOOTP in its current form quite
  1242.    insecure.  BOOTP is built directly upon UDP and IP which are as yet
  1243.    inherently insecure themselves.  Furthermore, BOOTP is generally
  1244.    intended to make maintenance of remote and/or diskless hosts easier.
  1245.    While perhaps not impossible, configuring such hosts with passwords or
  1246.    keys may be difficult and inconvenient.  This makes it difficult to
  1247.    provide any form of reasonable authentication between servers and
  1248.    clients.
  1249.  
  1250.    Unauthorized BOOTP servers may easily be set up.  Such servers can
  1251.    then send false and potentially disruptive information to clients such
  1252.    as incorrect or duplicate IP addresses, incorrect routing information
  1253.    (including spoof routers, etc.), incorrect domain nameserver addresses
  1254.    (such as spoof nameservers), and so on.  Clearly, once this "seed"
  1255.    mis-information is planted, an attacker can further compromise the
  1256.    affected systems.
  1257.  
  1258.    Unauthorized BOOTP relay agents may present some of the same problems
  1259.    as unauthorized BOOTP servers.
  1260.  
  1261.    Malicious BOOTP clients could masquerade as legitimate clients and
  1262.    retrieve information intended for those legitimate clients.  Where
  1263.    dynamic allocation of resources is used, a malicious client could
  1264.    claim all resources for itself, thereby denying resources to
  1265.    legitimate clients.
  1266.  
  1267. Author's Address
  1268.  
  1269.    Walt Wimer
  1270.    Network Development
  1271.    Carnegie Mellon University
  1272.    5000 Forbes Avenue
  1273.    Pittsburgh, PA  15213-3890
  1274.  
  1275.    Phone: (412) 268-6252
  1276.    EMail:  Walter.Wimer@CMU.EDU
  1277.  
  1278.  
  1279.  
  1280.  
  1281.  
  1282.  
  1283.  
  1284.  
  1285.  
  1286.  
  1287.  
  1288.  
  1289.  
  1290. Wimer                                                          [Page 23]
  1291.  
  1292.